Onderwerp: Polar performance, speed plugin voor SignalK maken

hanst schreef : True wind komt meestal niet uit een windset, die moet berekend worden. Doet SK dat?

Ruwe waterspeed zonder correcties voor de afwijkingen (verschillend per boeg en per snelheid) is niet echt nuttig.

Optimal VMG angle en bijbehorende boat speed staan in de polar per TWS.

Ik zou de interpolatie (TWS en TWA) meteen meenemen, anders krijg je wel erg groffe performance-resultaten.

Zou het niet heel wat slimmer zijn als jullie de koppen bij elkaar steken?

Een hoop van de berekeningen in SPD kunnen makkelijk in de plugin opgenomen worden. Een soort van light versie zeg maar.

Dat klinkt logisch inderdaad, maar SPD is nu dusdanig anders van opzet, dat dat óók vanaf scratch beginnen zou betekenen.

Je mag mijn code van het PolarPlot project (Free Pascal) ook gebruiken, als je daar wat aan hebt:
zeilersforum.nl/index.php/foru...ox?start=%1$d#642539

Vergis je niet in de hoeveelheid werk om dit robuust te maken voor alle situaties!

Hier een overzicht van de rekenstructuur die ik gebruikt heb, onderaan wat literatuurverwijzingen :
zeilersforum.nl/index.php/foru...ox?start=%1$d#658670

Baasklusje schreef :
Ja, die kan al standaard met 'derived data' plugin gemaakt worden.
Baasklusje schreef : Dus daar moet een correctie tabel voor komen. Daar is ook een standaard plugin voor, maar dan moet je wel eerst weten wat het zou moeten worden.
Voor nu zie ik dat als een optimalisatie voor op de lijst.
Baasklusje schreef :
Dat denk ik ook. Die staat bovenaan de lijst van optimalisaties. Het is meer dat ik nog geen algoritme heb gezocht/gevonden die dat gemakkelijk maakt.
Ik kan wel beginnen met een lineare interpolatie tussen de twee dichtsbijzijnde datapunten, maar snap ook wel dat dat nogal simpel is.

Nachtvlinder schreef :
Het doel voor mij is niet een product te maken, maar een begin van iets dat het makkelijk maakt voor anderen om het in stapjes te verbeteren.

Je rekenstructuur is heel verhelderend! Een tidel schakelaar voor boat speed lijkt me meteen een goede optie

hanst schreef :
Je hebt 4 datapunten:
de target snelheid in kts voor
- de TWS net boven de gemeten TWS
- de TWS net onder de gemeten TWS
- de TWA net boven de gemeten TWA
- de TWA net boven de gemeten TWA.

Twee keer interpoleren dus, voor snelheid en voor hoek.
Lineair is goed genoeg; het verschil met subtiele krommen is marginaal.

hanst schreef :
Tussen 0° en BeatAngle en tussen RunAngle en 180° kan je m.b.v. een cosinus de exacte waarde bepalen, je moet daar immers je VMG halen. Tussen alle andere TWA's is lineare interpolatie naar mijn idee de beste benadering.
Je kan wel proberen een of andere kromme door die punten te trekken, maar waar baseer je dat dan op? Als er tussen twee hoeken uit de meetbrief een overgang zit tussen genua en spi kan het best zijn dat de lineare interpolatie minder afwijking heeft dan een mooie vloeiende lijn.

Het wordt dan zoiets:

holtere schreef :
Ik wil best vertellen wat er in SPD gebeurt en hoe dat gaat; veel is al beschreven door Nachtvlinder en veel staat in de SPD Manual.

Maar een plug in voor SK maken is tegen mijn principes
Plug-in technieken zijn veel te gevoelig voor wijzigingen hier of daar.
(zie daarvoor alle draadjes hier over OpenCPN, Openplotter, de radar-plugin, de kaarten-ellende, etc).

Ik heb SPD bewust geheel stand alone gemaakt: niets anders bij nodig dan inkomende NMEA0183-berichten.
Ook de output is met industrie-standaards, weer NMEA0183, TCP, UDP en JSON over een webserver, HTML in elke browser. Niets plug-innerigs aan.

Elke vorm van Close Coupling die niet per sé nodig is tracht ik te vermijden.
Voor horror-verhalen over ongelukken door Close Coupling: lees het boek "Normal Accidents" van Charles Perrow, over Radar-Assisted Collisions, instortende mijnen, leeglopende meren, rampen in kerncentrales etc etc. Fascinerend boek, en voor mij reden om altijd verre van close coupling (lees: plug in afhankelijkheden) weg te blijven

On Topic maar weer!

De berekeningen (in deze volgorde) in SPD:

AWA correctie voor helling, drift en upwash (helling en drift of berekend of gemeten, upwash berekend)
AWS correctie voor helling en voor meetafwijking windset
Deviatiecorrectie opzoeken voor de gegeven HDG in 2D-tabel (actuele koers en 1 van 9 hellingstoestanden)
STWcorrectie opzoeken voor gegeven STW en 1 van 9 hellingstoestanden
(helling hiervoor is gemeten, indien niet beschikbaar dan uit polar)
HDG corrigeren voor actuele deviatie uit tabel
STW corrigeren voor actuele afwijking uit tabel
Grondwind (GEOwind) berekenen, richting 0-360 en snelheid. Berekening is afhankelijk van hoeveelheid stroom
Theoretische drift berekenen (K-factor)
De SOG in de lengte-as berekenen
Stroom berekenen (snelheid, richting tov de boot, tov de grond en impact op de boot)
AWA corrigeren voor masthoogte (windshear op hoogte, Coriolis)
True Wind (TWS en TWA) berekenen, afhankelijk van stroming, met STW of SOG (switchbaar met scherm-knop)
Upwash berekenen (formules Arvel Gentry)
Target Heel uit tabel van polar zoeken voor TWS en TWA
Beste UA en DA uit Polar opzoeken vor actuele TWS
Target Speed interpoleren voor TWA en TWS uit de polar
Target Speed berekenen voor < UA of > DA (zie Menno, cosinus)
VMG berekenen voor actuele TWA
Performance berekenen obv SOG en obv STW: 5 soorten performance:
(met STW, met SOG met stroom, met SOG zonder stroom, SOG naar WP, Actuele VMG tov Target VMG)
Tijd en Afstand naar Layline berekenen
Verder zit SPD vol met filtering, demping, tijdreeksen bijhouden, logging etc. En natuurlijk vele soorten output en adviezen. Het praat zelfs tegen je

Ik heb veel belangstelling voor zo'n plugin. Maar wil wel de volgende suggestie doen.

Vermijdt om in een plugin zowel de beschikbare data te verbeteren als om hier nuttige informatie uit te destilleren. Maak niet één plugin voor alles.

Het is beter om de verschillende functies te scheiden in verschillende plugins. Waarom? Enerzijds zijn er mensen die misschien wel hun stw gecorrigeerd willen hebben voor helling maar die niet geïnteresseerd zijn in performance data. Anderzijds bestaan er ook logs die al voor helling kunnen corrigeren (dst810 bv). Mensen met zo'n log zitten niet te wachten op nog een correctie. Hetzelfde geldt voor helling correctie van AWA en TWA. Als je een WS310/WS320 hebt van B&G en helling info op je netwerk, dan vindt zo'n correctie al plaats. Nog een keer corrigeren leidt tot slechtere data.

je kunt natuurlijk alles optioneel maken maar het doel van je programma, je code en je interface wordt er niet beter van. Ik heb al te veel van dat soort programma's gezien en terzijde geschoven.

Wat ik nog nuttige info zou vinden op basis van polar is de optimale windhoek gegeven een bepaalde windsterkte. Die kan gelijk gebruikt worden in de B&G performance plugin die je eerder maakte.

Aswin schreef :
Maar voor sommige nuttige info (performance!) heb je correcte data nodig.
Zo is performance berekenen op basis van een STW die 10% of meer afwijkt (en over de andere boeg weer anders) niet erg nuttig. En dan krijg je als je meerdere plugins daarvoor maakt meteen een afhankelijkheid tussen plugins.....

Correcties aan en uit zetten moet idd wel kunnen. Als een gever zelf al corrigeert hoeft het niet nog een keer. (in SPD is elke correctie aan of uit te zetten).

ik snap t wel hoor. Het is maar een indicatie. Nou zal de jouwe wat nauwkeuriger zijn, maar het blijft een indicatie.
En dat is ook best voldoende voor de meesten hier.

Het is leuk om tijdens het zeilen te proberen de performance omhoog te krijgen met wat spelen. Zo doe ik dat ook op de roosmux met multiview.
Het maakt ook niet echt uit of de performance per ongeluk, of niet perse door mijn kennis toch omhoog gaat.

En als de boot niet loopt voel ik dat meteen. Heb ik geen display voor nodig. En daar kan ik dan wel weer chaggerijnig van worden soms. Er gaat dan toch een ander zeil op, ondanks de inspanning die daar voor nodig is.

Aswin schreef : Mee eens. Dat zou ook niet in lijn zijn met de opzet van SignalK.
Aswin schreef :
Welke term is dit? Optimum Wind Angle is het volgens mij niet. User defined kan natuurlijk ook.

Op de meetbrief heet dat UA en DA.
Wel even interpoleren.

Baasklusje schreef : Dat klopt. Je hebt dan meerdere plugins nodig voor correcte data. Maar dat is precies het idee achter het gebruik van plugins, dat je een modulair systeem hebt waarin je precies die bouwstenen toevoegt die jij nodig hebt en alle andere niet.
En de afhankelijkheid tussen plugins beperkt zich tot het doorgeven van data. Daar heeft signal-K een heel mooi datamodel voor gemaakt. De data komt er precies zo aan zoals je het verwacht en je kiest zelf de bron die je gebruikt. Dus bv de plugin die de AWA corrigeert gebruikt als bron de NMEA-in en de plugin die TWA berekent kan je zo instellen dat hij de gecorrigeerde AWA kiest en niet de ongecorrigeerde. Dat werkt prima.
@Baasklusje. Je zou Signal-K zoveel mooier kunnen maken als je principes je er niet van weerhielden.

Mijn 'SPD plugin' werkt prima

Baasklusje schreef :
Gedeeltelijk mee eens.

Dit geldt volgens mij vooral als je met eigen instrumenten en een gegeven polar werkt.
Dan is nog wel de vraag waar de correctie moet/kan plaatsvinden. Het liefst gebeurd dat al voordat de data gedeeld wordt, dus bijvoorbeeld in de sensor. Met de nieuwere kan dat dan ook, maar met oudere niet.
SignalK kan dat doen bij het inlezen vanaf de bus. Dat is dan een logischere plek om dit te doen dan verderop, omdat zo alle gebruikers van de data dezelfde gecorrigeerde data gebruiken.

Als je je eigen polar diagram opbouwt met je eigen instrumenten, dan maakt het allemaal minder uit volgens mij. De polar is dan 'scheef', maar werkt wel in die zin dat het je helpt om zien of je eerder harder bent gegaan toen de instrumenten dezelfde data doorgaven. En dat is waar veel cruisers volgens mij meer in geinteresseerd zijn.

Shutter Speed schreef :
Dat dacht ik nou ook.
SPD interfacet netjes via openbare standaarden met SK. Twee kanten op ook nog, input en output. Ik zie geen enkele toegevoegde waarde in een plugin. Alles kan nu ook al. Maar het is vast leuk om er een te maken.

hanst schreef :
Ik dacht juit wel dat het optimum wind angle was.

Even off-topic nog… In een ander draadje omschreef ik waarom ik vind dat een performance berekening beter als SignalK plugin dan als stand-alone programma gebouwd kan worden:

Nachtvlinder schreef :
Goed idee dus, dit draadje. Ook om correcties als separate plugin te bouwen!

PS: leeway schatting zit al in de “derived data” plugin

Blijft een fascinerend onderwerp welk ik met belangstelling volg. Altijd met de hoop dat iemand met een briljante oplossing komt om met een goede nauwkeurigheid STW te meten.

Aswin schreef :
Ik dacht juit wel dat het optimum wind angle was.[/quote]

Ik ben er niet helemaal in thuis, maar ik lees:
UA = Upwind Angle - hoek aan de wind met grootste VMG
DA = Downwind Angle - hoek voor de wind met grootste VMG

Afhankelijk van upwind/downwind is dit de Target Wind Angle (TWA).
Optimum Wind Angle volgens deze B&G manual is het verschil tussen de huidige wind angle en de target wind angle. Ik vermoed dat deze dan met zo'n groen/rood pijltje wordt weergegeven.

Als je het hardst met je boot wilt gaan gemeten in bootsnelheid, dus niet VMG, dan kijk je wanneer de boat speed het hoogst is. Normaal ergens rond halve wind. Die wind angle is bij racen niet interessant omdat je altijd ergens heen moet.

Of begreep ik je vraag verkeerd?

Disclaimer. Onder helling is het nog niet zo goed. Daarvoor heb ik meer datapunten nodig.

Aswin schreef :
Meerdere plugins om correcte informatie te krijgen is niet nodig als je het ook in een keer kan doen. Dat verkleint het risico dat de gebruiker iets verkeerd doet of vergeet toe te voegen.

Signal K mooier maken..... ik heb al (veel) eerder gezegd dat ik het een 'oplossing op zoek naar een passend probleem' vind. En dat vind ik nog steeds.
Daarbij uiterst inefficiënt, berichten zijn zomaar 100-en keren langer dan die van NMEA.
Dat moet allemaal getransporteerd en geïnterpreteerd worden.

Ik ben geinteresseerd in software die correcte informatie maakt door data te combineren.
Het steeds weer op een nieuwe manier (Tommy/Kip) displayen van data die ergens anders al te zien was is niet nuttig. En dat is wat ik veel zie gebeuren rond SK. Weer een schermpje met foutief berekende TWA....

Mijn oplossing blijft:
- een goede multiplexer die ST, NMEA0183, N2K inputs combineert, vertaalt en dat ook allemaal kan versturen en filteren. Miniplex 3 N2K.
- via USB al die data naar een PC. Geen losse converters nodig.
- gebruik van industrie-standaarden (0183, N2K, USB, UDP, TCP, webserver, browser, html.
Dat ik dan de olietemperatuur in de keerkoppeling of de vulling van de watertank niet elke seconde kan aflezen (die vertaalt de Miniplex niet) zal me een rotzorg zijn.

Er zijn flink wat gebruikers die SK en SPD gebruiken op deze manier. Dat verzamelen in SK, als 0183 naar SPD en er weer uit, en dan vertalen in SK naar wat je maar wil. Zie SPD als een soort loszittende plugin
En daarnaast werkt het natuurlijk ook stand alone. Voor al die mensen zonder SK.